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Abstract 

Higher-order abstract syntax is a simple technique for implement- 
ing languages with functional programming. Object variables and 
binders are implemented by variables and binders in the host lan- 
guage. By using this technique, one can avoid implementing com- 
mon and tricky routines dealing with variables, such as capture- 
avoiding substitution. However, despite the advantages this tech- 
nique provides, it is not commonly used because it is difficult to 
write sound elimination forms (such as folds or catamorphisms) for 
higher-order abstract syntax. To fold over such a datatype, one must 
either simultaneously define an inverse operation (which may not 
exist) or show that all functions embedded in the datatype are para- 
metric. 

In this paper, we show how first-class polymorphism can be used to 
guarantee the parametricity of functions embedded in higher-order 
abstract syntax. With this restriction, we implement a library of it- 
eration operators over data-structures containing functionals. From 
this implementation, we derive "fusion laws" that functional pro- 
grammers may use to reason about the iteration operator. Finally, 
we show how this use of parametric polymorphism corresponds 
to the Schiirmann, Despeyroux and Pfenning method of enforcing 
parametricity through modal types. We do so by using this library 
to give a sound and complete encoding of their calculus into System 
F m . This encoding can serve as a starting point for reasoning about 
higher-order structures in polymorphic languages. 

Categories and Subject Descriptors 

D.3.3 [PROGRAMMING LANGUAGES]: Language Constructs 
and Features — abstract data types, polymorphism, control struc- 
tures; F.3.3 [LOGICS AND MEANINGS OF PROGRAMS]: 
Software — type structure, program and recursion schemes, func- 
tional constructs; F.4.1 [MATHEMATICAL LOGIC AND FOR- 
MAL LANGUAGES]: Mathematical Logic — Lambda calculus 
and related systems, modal logic 
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1 Introduction 

Higher-order abstract syntax (HOAS) is an old and seductively sim- 
ple technique for implementing a language with functional pro- 
gramming. 1 The main idea is elegant: instead of representing ob- 
ject variables explicitly, we use metalanguage variables. For ex- 
ample, we might represent the object calculus term (kx.x) with 
the Haskell expression lam (\x -> x). Doing so eliminates the 
need to implement a number of tricky routines dealing with object 
language variables. For example, capture-avoiding substitution is 
merely function application in the metalanguage. However, out- 
side of a few specialized domains, such as theorem proving, partial 
evaluation [26], logical frameworks [22] and intensional type anal- 
ysis [27, 30], higher-order abstract syntax has found limited use as 
an implementation technique. 

One obstacle preventing the widespread use of this technique is the 
difficulty in using elimination forms, such as catamorphisms , for 
datatypes containing functions. The general form of catamorphism 
for these datatypes requires that an inverse be simultaneously de- 
fined for every iteration [16]. Unfortunately, many operations that 
we would like to define with catamorphisms require inverses that 
do not exist or are expensive to compute. 

However, if we know that the embedded functions in a datatype are 
parametric, we can use a version of the catamorphism that does not 
require an inverse [9, 24]. A parametric function may not examine 
its argument; it may only use it abstractly or "push it around". Only 
allowing parametric embedded functions works well with HOAS 
because the terms with non-parametric embedded functions are ex- 
actly those that have no correspondence to any X-calculus term [24], 
In this paper, we use iterator to refer to a catamorphism restricted 
to arguments with parametric functions. 

A type system can separate parametric functions from those that 

'While the name comes from Pfenning and Elliott [21], the idea 
itself goes back to Church. [4]. 

2 Catamorphisms (also called folds) are sometimes represented 
with the bananas (| • |) notation [15]. 



are not. For example, Fegaras and Sheard [9] add tags to mark 
the types of datatypes whose embedded functions are not para- 
metric, prohibiting iteration over those datatypes. Alternatively, 
Schiirmann, Despeyroux and Pfenning [24, 8] use the necessity 
modality ("box") to mark those terms that allow iteration. 

However, many modern typed languages already have a mechanism 
to enforce that an argument be used abstractly — parametric poly- 
morphism. It seems desirable to find a way to use this mechanism 
instead of adding a separate facility to the type system. In this pa- 
per, we show how to encode datatypes with parametric function 
spaces in the polymorphic A.-calculus, including iteration operators 
over them. 

Our specific contributions are the following. For functional pro- 
grammers, we provide an informal description of how restricting 
datatypes to parametric function spaces can be enforced in the 
Haskell language using first-class polymorphism. We provide a safe 
and easy implementation of a library for iteration over higher-order 
abstract syntax. This Haskell library allows the natural expression 
of many algorithms over the object language; to illustrate its use, 
we use it to implement a number of operations including Danvy 
and Filinski's optimizing one-pass CPS conversion algorithm [6]. 
Furthermore, because we encode the iteration operator within the 
polymorphic X-calculus, we also derive "fusion laws" about the 
iteration operator that functional programmers may use to reason 
about their programs. 

To show the generality of this technique, we use this implementa- 
tion to show a formal translation from the Schiirmann, Despeyroux 
and Pfenning modal calculus [24] (called here the SDP calculus) 
to System Fa,. This encoding has an added benefit to language de- 
signers who wish to incorporate reasoning about parametric func- 
tion spaces. It demonstrates how systems based on the polymor- 
phic X-calculus may be extended with reasoning about higher-order 
structure. 

We do not claim that this encoding will solve all of the problems 
with programming using higher-order abstract syntax. In particular, 
algorithms that require the explicit manipulation of the names of 
bound variables remain outside the scope of this implementation 
technique. 

The remainder of this paper is as follows. Section 2 starts with 
background material on catamorphisms for HO AS, including those 
developed by Meijer and Hutton [16] and Fegaras and Sheard [9]. 
In Section 2.1 we show how to use first-class polymorphism and ab- 
stract types to provide an interface for Fegaras and Sheard's imple- 
mentation that enforces the parametricity of embedded functions. 
Using this interface, we show some examples of iteration includ- 
ing CPS conversion (Section 2.2). In Section 3, we describe an 
implementation of that interface within the part of Haskell that cor- 
responds to System F ra , and describe properties of that implemen- 
tation in Section 3.1. Section 4 describes the SDP calculus and 
Section 5 presents an encoding of that calculus into F ra , using the 
implementation that we developed in Section 3. Section 6 presents 
future work, Section 7 presents related work, and Section 8 con- 
cludes. We include Generic Haskell code for the polytypic part of 
our implementation in Appendix A and the full encoding of the SDP 
calculus into System F ra in Appendix B. 



2 Catamorphisms for datatypes with embed- 
ded functions 

The following recursive datatype represents the untyped A.-calculus 
using Higher-Order Abstract Syntax (HOAS). 3 

data Exp = Lam (Exp -> Exp) I App Exp Exp 

The data constructor Lam represents ^-expressions. How- 
ever, instead of explicitly representing bound X-calculus 
variables, Haskell functions are used to implement binding 
and Haskell variables are used to represent variables. For 
example, we might represent the identity function (Xx.x) as 
Lam (\x -> x) or the infinite loop (hc.(xx))(hc.(xx)) as 
App (Lam (\x -> App x x) ) (Lam (\x -> App x x) ) . 

Using this datatype, we can implement an interpreter for the X- 
calculus. To do so, we must also represent the result values (also 
using HOAS). 

data Value = Fn (Value -> Value) 
unFn (Fn x) = x 

It is tricky to define recursive operations, such as evaluation, over 
this implementation of expressions. The argument, x, to Lam below 
is a function of type Exp -> Exp. To evaluate it, we must convert 
x to a function of type Value -> Value. Therefore, we must also 
simultaneously define an inverse to evaluation, called uneval, such 
that eval . uneval = \x -> x. This inverse is used to convert 
the argument of x from a Value to an Exp. 

eval : : Exp -> Value 

eval (Lam x) = Fn (eval . x . uneval) 
eval (App y z) = unFn (eval y) (eval z) 
uneval : : Value -> Exp 

uneval (Fn x) = Lam (uneval . x . eval) 

Consider the evaluation of ((Xx.x)(Xy.y)). First eval replaces App 
with unFn and pushes evaluation down to the two subcomponents 
of the application. Next, each Lam is replaced by Fn, and the argu- 
ment is composed with eval and uneval. The unFn cancels the 
first Fn, and the identity functions can be removed from the com- 
positions. As uneval is right inverse to eval, we can replace each 
(eval . uneval) with the identity function. 

eval (App (Lam (\x -> x) ) (Lam (\y -> y))) 
= unFn (eval (Lam (\x -> x))) 
(eval (Lam (\y -> y) ) ) 
= unFn (Fn (eval . \x -> x . uneval)) 
(Fn (eval . \y -> y . uneval)) 
= (eval . uneval) (Fn (eval . uneval)) 
= (\x -> x) (Fn (\y -> y)) 
= Fn (\y -> y) 

Many functions defined over Exp will follow this same pattern of 
recursion, requiring an inverse for Lam and calling themselves re- 
cursively for the subcomponents of App. Catamorphisms capture 
the general pattern of recursion for functions defined over recur- 
sive datatypes. For example, f oldl is a catamorphism for the list 
datatype and can implement many list operations. For lists of type 



All of the following examples are in the syntax of the Haskell 
language [19]. While some of the later examples require an exten- 
sion of the Haskell type system — first-class polymorphism — this 
extension is supported by the Haskell implementations GHC and 
Hugs. 



newtype Rec a = Roll (a (Rec a)) 

data ExpF a = Lam (a -> a) I App a a 
type Exp = Rec ExpF 

lam : : (Exp -> Exp) -> Exp 

lam x = Roll (Lam x) 

app : : Exp -> Exp -> Exp 

app x y = Roll (App x y) 

xmapExpF : : (a -> b, b -> a) 

-> (ExpF a -> ExpF b, ExpF b -> ExpF a) 
xmapExpF (f,g) = (\x -> case x of 

Lam x -> Lam (f . x . g) 
App y z -> App (f y) (f z) , 
\x -> case x of 

Lam x -> Lam (g . x . f) 
App y z -> App (g y) (g z)) 

cata : : 

(ExpF a -> a) -> (a -> ExpF a) -> Rec ExpF -> a 
cata f g (Roll x) = 

f ((fst (xmapExpF (cata f g, ana f g) ) ) x) 

ana : : 

(ExpF a -> a) -> (a -> ExpF a) -> a -> Rec ExpF 
ana f g x = 

Roll (snd (xmapExpF (cata f g, ana f g) ) (g x)) 
Figure 1. Meijer/Hutton catamorphism 



[a] , f oldr replaces [] with a base case of type b and ( : ) with a 
function of type (a -> b -> b). 

Meijer and Hutton [16] showed how to define catamorphisms 
for datatypes with embedded functions, such as Exp. The cata- 
morphism for Exp systematically replaces Lam with a function 
of type ((a -> a) -> a) and App with a function of type 
(a -> a -> a). However, just as we defined eval simul- 
taneously with uneval, the catamorphism for Exp must be 
simultaneously defined with an anamorphism. The catamor- 
phism provides a way to consume members of type Exp and the 
anamorphism provides a way to generate them. 

In order to easily specify this anamorphism, we use a slightly more 
complicated version of the Exp datatype, shown at the top of Fig- 
ure 1 . This version makes the recursion in the datatype explicit. The 
newtype Rec computes the fixed point of type constructors (func- 
tions from types to types). The type Exp is the fixed point of the 
type constructor ExpF, where the recursive occurrences of Exp have 
been replaced with the type parameter a. The first argument to cata 
is of type ExpF a -> a (combining the two functions mentioned 
above, of type ((a -> a) -> a) and (a -> a -> a)). The first 
argument to ana has the inverse type a -> ExpF a. 

The functions cata and ana are defined in terms of xmapExpF, a 
generalized version of a mapping function for the type construc- 
tor ExpF. Because of the function argument to Lam, xmapExpF 
maps two functions, one of type a -> b and the other of type 
b -> a. The definition of xmapExpF is completely determined by 
the definition of ExpF. With Generic Haskell [5], we can define 
xmap and automatically generate xmapExpF from ExpF (see Ap- 



data Rec a b = Roll (a (Rec a b)) I Place b 

data ExpF a = Lam (a -> a) I App a a 
type Exp a = Rec ExpF a 

lam : : (Exp a -> Exp a) -> Exp a 

lam x = Roll (Lam x) 

app : : Exp a -> Exp a -> Exp a 

app x y = Roll (App x y) 

xmapExpF : : (a -> b, b -> a) 

-> (ExpF a -> ExpF b, ExpF b -> ExpF a) 
xmapExpF (f,g) = (\x -> case x of 

Lam x -> Lam (f . x . g) 

App y z -> App (f y) (f z) , 

\x -> case x of 

Lam x -> Lam (g . x . f) 

App y z -> App (g y) (g z)) 

cata : : (ExpF a -> a) -> Exp a -> a 
cata f (Roll x) = 

f ((fst (xmapExpF (cata f, Place))) x) 
cata f (Place x) = x 

Figure 2. Fegaras/Sheard catamorphism 



pendix A). 4 That way, we can easily generalize this catamorphism 
to other datatypes. Unlike map, which is defined only for covari- 
ant type constructors, xmap is defined for type constructors that 
have both positive and negative occurrences of the bound variable. 
The only type constructors of Fm for which xmap is not defined are 
those whose bodies contain first-class polymorphism. For example, 
la : *.VfS : *.a -> p. 

We can use cata to implement eval. To do so we must de- 
scribe one step of turning an expression into a value (the function 
evalAux) and one step of turning a value into an expression (the 
function unevalAux). 

evalAux : : ExpF Value -> Value 
evalAux (Lam f) = Fn f 
evalAux (App x y) = (unFn x) y 

unevalAux : : Value -> ExpF Value 
unevalAux (Fn f) = Lam f 

eval : : Exp -> Value 

eval x = cata evalAux unevalAux x 

Using cata to implement operations such as eval is convenient 
because the pattern of recursion is already specified. None of eval, 
evalAux or unevalAux are recursively defined. However, for some 
operations, there is no obvious (or efficient) inverse. For exam- 
ple, to using cata to print out expressions also requires writing a 
parser. Fegaras and Sheard [9] noted that sometimes the operation 
of the catamorphism often undoes with f what it has just done with 

4 Meijer and Hutton' s version of xmapExpF only created the first 
component of the pair. In ana where the second component is 
needed, they swap the arguments. This is valid because fst (xmap 
(f,g)) = snd(xmap (g,f)). However, while the version that 
we use here is a little more complicated, it can be defined with 
Generic Haskell. 



g. This situation occurs when the argument to cat a contains only 
parametric functions. A parametric function is one that does not 
analyze its argument with case or cata. 

When the argument to cata is parametric, Fegaras and Sheard 
showed how to implement cata without ana. The basic idea is that 
for parametric functions, any use of ana during the computation of 
a catamorphism will always be annihilated by cata in the final re- 
sult. Therefore, instead of computing the anamorphism, they use 
a place holder to store the original argument. When cata reaches 
that place holder, it returns the stored argument. 

To implement Fegaras and Sheard's catamorphism, we must rede- 
fine Rec. In Figure 2, we extend it with an extra branch (called 
Place) that is the place holder. Because Place can contain any 
type of value, Rec (and consequently Exp) must be parameterized 
with the type of the argument to Place. This type is the result of the 
catamorphism over the expression. In the implementation of cata, 
Place is the second argument to xmapExpF instead of ana f . It is 
a right inverse to cata f by definition. 

For example, to count the number of occurrences of bound variables 
in an expression, we might use the following code. 

countvarAux : : ExpF Int -> Int 
countvarAux (App x y) = x + y 
countvarAux (Lam f) = f 1 

countvar : : Exp Int -> Int 
countvar = cata countvarAux 

The function countvarAux describes what to do in one step. The 
number of variables in an application expression is the sum of the 
number of variables in x and the number of variables in y. In the 
case of a A.-expression, f is a function from the number of variables 
in a variable expression (i.e. one) to the number of variables in the 
body of the lam. For example, to count the variables in (he. x x): 

countvar (lam (\x -> app x x) ) 

= (countvar . (\x -> x + x) . Place) 1 
= (\x -> (countvar (Place x)) 

+ (countvar (Place x) ) ) 1 
= (countvar (Place 1)) + (countvar (Place 1)) 
= 2 

This definition of cata only works for arguments whose function 
spaces are parametric and who do not use Place. Informally, we 
call such expressions sound and other expressions unsound. Apply- 
ing cata to an unsound expression can return a meaningless result. 
For example, say we define the following term: 

badplace : : Exp Int 

badplace = lam (\x -> Place 3) 

Then countvar badplace = 3, even though it contains no bound 
variables. Even more importantly for higher-order abstract syntax, 
unsound datatypes do not correspond to untyped A.-calculus expres- 
sions, so it is important to be able to distinguish between sound and 
unsound representations. 5 



It is also important to distinguish between sound and unsound 
members of datatypes that have meaningful non-parametric repre- 
sentations. For these datatypes, the behavior of the Fegaras and 
Sheard catamorphism on unsound arguments does not correspond 
to the Meijer and Hutton version. 



There are two ways for parametricity to fail, corresponding to the 
two destructors for the type Exp a. A function is not parametric if 
it uses cata or case to examine its argument, as below: 

badcata : : Exp Int 

badcata = lam (\x -> if (countvar x == 1) 
then app x x 
else x) 

badcase : : Exp a 

badcase = lam (\x -> case x of 

Roll (App v w) -> app x x 

Roll (Lam f) -> x 

Place v -> x) 

Fegaras and Sheard designed a type system to distinguish between 
sound and unsound expressions. Datatypes such as Exp were an- 
notated with flags to indicate whether they had been examined with 
either case or cata, and if so, they were prevented from appearing 
inside of non-flagged datatypes. Furthermore, their language pre- 
vented the user from accessing Place by automatically generating 
cata from the definition of the user's datatype. 

2.1 Enforcing parametricity with type ab- 
straction 

The type of badcata is Exp Int. This type tells us that something 
is wrong: the type parameter of Exp is constrained to be Int, so 
we can only use cata on this expression to produce an Int. The 
same is true for badplace. Whenever we use cata or Place in 
an expression, this parameter will be constrained. If we can ensure 
that only sound expressions have type (for all a. Exp a), then 
we can use first-class polymorphism to enforce that the argument to 
a function is sound. That way, we can be assured that it will behave 
as expected. For example, define a version of cata, called iterO 
that may only be applied to sound expressions, below. The imple- 
mentation of cata uses the argument at the specific type (Exp a) , 
so it is safe for iterO to require that its argument has the more 
general type (forall a. Exp a). 

iterO : : (ExpF b -> b) -> (forall a. Exp a) -> b 
iterO = cata 

However, this new type does not prevent expressions like badcase 
from being the argument to iterO. We can prevent such case anal- 
ysis inside lam expressions by ruling out case analysis for all terms 
of type Exp t. If the user cannot use case, then they cannot write 
badcase. While this restriction means that some operations cannot 
be naturally defined in this calculus, cata alone can define a large 
number of operations, as we demonstrate below and in Section 2.2. 

There are two ways to prohibit case analysis. The first way is to 
reimplement Exp in such a way that cata is the only possible oper- 
ation (in other words without using a Haskell datatype). We discuss 
this alternative in Section 3. 

The second way to prohibit case analysis is to make Rec an abstract 
type constructor. If the definition of Rec is hidden by some module 
boundary, such as with the interface in Figure 3, then the only way 
to destruct an expression of type Exp a is with cata. Because 
Roll and Place are datatype constructors of Rec, and cata pattern 
matches these constructors, they must all be defined in the same 
module as Rec. However, because we only need to prohibit case 
analysis, we can export Roll and Place as the functions roll and 
place. With roll we can define the terms app and lam anywhere. 



type Rec a b — abstract 

data ExpF a = Lam (a -> a) I App a a 

type Exp a = Rec ExpF a 



roll 

place 

cata 



ExpF (Exp a) -> Exp a 
a -> Exp a 

(ExpF a -> a) -> Exp a -> a 



Figure 3. Iteration library interface 



Each of these iterators is defined by using xmap to map (cata f ) 
and place. Thus we can easily implement them by defining the 
appropriate version of xmap. However, because xmap is a polytypic 
function, we should be able to automatically generate all of these 
iterators using Generic Haskell. The following code implements 
these operations. Below, the notation xmap{ I g I } generates the in- 
stance of xmap for the type constructor g. 

openiter{|g :: * -> * 1} :: 

(ExpF a -> a) -> g (Exp a) -> g a 
openiter{|g|} f = 

fst (xmap{|g|} (cata f, place)) 



We can also make good use of place. The type forall a. Exp a 
enforces that all embedded functions are parametric, but it can only 
represent closed expressions. What if we would like to examine 
expressions with free variables? In HOAS, an expression with one 
free variable has type Exp t -> Exp t. To compute the catamor- 
phism for the expression, we use place to provide the value for the 
free variable. 

openiterl : : (ExpF b -> b) 

-> (Exp b -> Exp b) -> (b -> b) 
openiterl f x = \y -> cata f (x (place y)) 

If we would like to make sure that the expression is sound, we must 
quantify over the parameter type and require that the expression 
have type forall a. Exp a -> Exp a. 

iterl : : (ExpF b -> b) 

-> (forall a. Exp a -> Exp a) -> (b -> b) 
iterl = openiterl 

With iterl we can determine if that one free variable occurs in an 
expression. 

freevarused : : (forall a. Exp a -> Exp a) -> Bool 

freevarused e = 

iterl (\x -> case x of 

(App x y) -> x I I y 

(Lam f) -> f False) e True 

An app expression uses the free variable if either the function or the 
argument uses it. The occurrence of the bound variable of a lam is 
not an occurrence of the free variable, so False is the argument to 
f , but the expression does use the free variable if it appears some- 
where in the body of the abstraction. Finally, the program works 
by feeding in True for the value of the free variable. If the result is 
True then it must have appeared somewhere in the expression. 

There is no reason to stop with one free variable. There are an infi- 
nite number of related iteration operators, each indexed by the type 
inside the forall. The types of several such iterators are shown 
below. For example, the third one, iterList, may analyze expres- 
sions with arbitrary numbers of free variables. 

iter2 : : (ExpF b -> b) 

-> (forall a. Exp a -> Exp a -> Exp a) 

-> (b -> b -> b) 
iterFun : : (ExpF b -> b) 

-> (forall a. (Exp a -> Exp a) -> Exp a) 

-> ((b -> b) -> b) 
iterList : : (ExpF b -> b) 

-> (forall a. ([Exp a] -> Exp a)) 

-> (M -> b) 



iter-Clg : : * -> * |} : : 

(ExpF a -> a) -> (forall b. g (Exp b)) -> g a 
iter{|g|} = openiter{ I g I > 

Unfortunately, the above Generic Haskell code cannot automat- 
ically generate all the iterators that we want, such as iterl, 
iterFun and iterList. Because of type inference, g can only 
be a type constructor that is a constant or a constant applied to type 
constructors [13]. In particular, we cannot represent the type con- 
structor (Xa : *.oc — > a) in Haskell, so we cannot automatically gen- 
erate the instance 

iterl : : (f b -> b) 

-> (forall a. (Exp a) -> (Exp a)) -> b -> b 

Fortunately, using a different extension of Haskell, called functional 
dependencies [14], we can generate these versions of openiter. 
For each version of iter that we want, we still need to redefine the 
generated openiter with the more restrictive type. 

iterl : : (ExpF a -> a) 

-> (forall b. Exp b -> Exp b) -> a -> a 
iterl = openiter 

The Iterable class defines openiter simultaneously with its in- 
verse. The parameters m and n should be g (Exp a) and g a, where 
each instance specifies g. (The type a is a parameter of the type 
class so that m and n may refer to it.) Also necessary are the func- 
tional dependencies that state that m determines both a and n. These 
dependencies rule out ambiguities during type inference. 

class Iterable amn|m->a, m->n where 
openiter : : (ExpF a -> a) -> m -> n 
uniter : : (ExpF a -> a) -> n -> m 

If g is the identity type constructor, then m and n are Exp a and a 
respectively. 

instance Iterable a (Exp a) a where 
openiter = cata 
uniter f = place 

Using the instances for the subcomponents, we can define instances 
for types that contain ->. 

instance (Iterable a ml nl, Iterable a m2 n2) 
=> Iterable a (ml -> m2) (nl -> n2) where 
openiter f x = openiter f . x . uniter f 
uniter fx = uniter f . x . openiter f 

With these instances, we have a definition for openiter{ I Xa.a —> 
a\y. It is not difficult to add instances for other type constructors, 
such as lists and tuples. 



2.2 Examples of iteration 

We next present several additional examples of the expressiveness 
of iterO for arguments of type (forall a. Exp a). The pur- 
pose of these examples is to demonstrate how to implement some 
of the common operations for X-calculus terms without case analy- 
sis. 

For example, we can use iterO to convert expressions to strings. 
So that we have different names for each nested binding occurrence, 
we must parameterize this iteration with a list of variable names. 
Haskell's list comprehension provides us with an infinite supply of 
strings. 

vars : : [String] 

vars = [ [i] I i <- ['a'..'z'] ] ++ 

[ i : show j I j <- [1..], i <- [>a'..'z>] ] 

showAux : : ExpF ( [String] -> String) 

-> ([String] -> String) 
showAux (App x y) vars = 

"(" ++ (x vars) ++ " " ++ (y vars) ++ ")" 
showAux (Lam z) (v:vars) = 

"(fn " ++ v ++ ". " ++ (z (const v) vars) ++ ")" 

show : : (forall a. Exp a) -> String 
show e = iterO showAux e vars 

Applying show to an expression produces a readable form of the 
expression. 

show (lam (\x -> lam (\y -> app x y))) 
= (fn a. (fn b. (a b) ) ) 

Another operation we might wish to perform for a A,-calculus ex- 
pression is to reduce it to a simpler form. As an example, we next 
implement parallel reduction for a A,-calculus expression. 6 Parallel 
reduction differs from full reduction in that it does not reduce any 
newly created redexes. Therefore, it terminates even for expres- 
sions with no p-normal form. Parallel reduction may be specified 
by the following inductive definition. 

xWx Ix.M => hc.M' MN => M'N' 

(fcc.M)N => M'{x/N'} 

We use iterO to implement parallel reduction below. The tricky 
part is the case for applications. We must determine whether the 
first component of an application is a lam expression, and if so, 
perform the reduction. However, we cannot do a case analysis on 
expressions, as the type Exp a is abstract. Therefore, we imple- 
ment parallel reduction with a "pairing" trick 7 . As we iterate over 
the term we produce two results, stored in the following record: 

data PAR a = PAR { par : : Exp a, 

apply : : Exp a -> Exp a } 

The first component, par, is the actual result we want — the parallel 
reduction of the term. The second component, apply, is a func- 

6 This example is from Schiirmann et. al [24]. 

7 Pairing was first used to implement the predecessor operation 
for Church numbers. The iteration simultaneously computes the 
desired result with auxiliary operations. 



tion that we build up for the application case. In the case of a lam 
expression, apply performs the substitution in the reduced term. 
Otherwise, apply creates an app expression with its argument and 
the reduced term. 8 

parAux : : ExpF (PAR a) -> PAR a 
parAux (Lam f) = 

PAR { par = lam (par . f . var) , 
apply = par . f . var }■ 

where 

var : : Exp a -> PAR a 

var x = PAR { par = x, apply = app x } 
parAux (App x y) = 

PAR { par = apply x (par y) , 

apply = app (apply x (par y)) } 

parallel : : (forall v. Exp v) -> (forall v. Exp v) 
parallel x = par (iterO parAux x) 

For example: 

show (parallel (app (lam (\x -> app x x)) 

(lam (\y -> y)))) 
= "((fn a. a) (fn a. a))" 

While we could not write the most natural form of parallel reduc- 
tion with iterO, other operations may be expressed in a very nat- 
ural manner. For example, we can implement the one-pass call-by- 
value CPS-conversion of Danvy and Filinski [6]. This sophisticated 
algorithm performs "administrative" redexes at the meta-level so 
that the result term has no more redexes than the original expres- 
sion. The algorithm is based on two mutually recursive operations: 
cpsmeta performs closure conversion given a meta-level continua- 
tion (a term of type Exp a -> Exp a), and cpsobj does the same 
with an object-level continuation (a term of type Exp a). 

data CPS a = CPS { 

cpsmeta : : (Exp a -> Exp a) -> Exp a, 
cpsobj : : Exp a -> Exp a } 

If we are given a value (i.e. a ^.-expression or a variable) the func- 
tion value below describes its CPS conversion. Given a meta- 
continuation k, we apply k to the value. Otherwise, given an object 
continuation c, we create an object application of c to the value. 

value : : Exp a -> CPS a 

value x = CPS { cpsmeta = \k -> k x, 

cpsobj = \c -> app c x y 

The operation cpsAux takes an expression whose subcomponents 
have already been CPS converted and CPS converts it. For applica- 
tion, translation is the same in both cases except that the meta-case 
converts the meta-continuation into an object continuation with 
lam. 

cpsAux : : ExpF (CPS a) -> CPS a 
cpsAux (App el e2) = 

CPS { cpsmeta = \k -> appexp (lam k) , 

cpsobj = appexp } 
where appexp c = 

(cpsmeta el) (\yl -> 
(cpsmeta e2) (\y2 -> 
app (app yl y2) c)) 



8 In Haskell, the notation apply x projects the apply compo- 
nent from the record x. 



type Rec f a = (f a -> a) -> a 

data ExpF a = Lam (a -> a) I App a a 

type Exp a = Rec ExpF a 

roll : : ExpF (Exp a) -> Exp a 
roll x = 

\f -> f (fst (xmapExpF (cata f, place)) x) 

place : : a -> Exp a 
place x = \f -> x 

lam : : (Exp a -> Exp a) -> Exp a 
lam x = roll (Lam x) 

app : : Exp a -> Exp a -> Exp a 
app y z = roll (App y z) 

xmapExpF : : (a -> b, b -> a) 

-> (ExpF a -> ExpF b, ExpF b -> ExpF a) 

xmapExpF (f,g) = (\x -> case x of 

Lam x -> Lam (f . x . g) 

App y z -> App (f y) (f z) , 

\x -> case x of 

Lam x -> Lam (g . x . f) 

App y z -> App (g y) (g z)) 

cata : : (ExpF a -> a) -> Exp a -> a 
cata f x = x f 

iterO :: (ExpF a -> a) -> (forall b. Exp b) -> a 
iterO = cata 

Figure 4. Catamorphism in the F a fragment of Haskell 



For functions, we use value, but we must transform the function 
to bind both the original and continuation arguments and transform 
the body of the function to use this object continuation. The outer 
lam binds the original argument. We use value for this argument 
in f and cpsob j yields a body expecting an object continuation that 
the inner lam converts to an expression. 

cpsAux (Lam f) = 

value (lam (lam . cpsobj . f . value) ) 

Finally, we start cps with iterO by abstracting an arbitrary dy- 
namic context a and transforming the argument with respect to that 
context. 

cps : : (forall a. Exp a) -> (forall a. Exp a) 
cps x = lam (\a -> 

cpsmeta (iterO cpsAux x) (\m -> app am)) 

show (cps (lam (\x -> app x x))) 

= "(fn a. (a (fn b. (fn c. ( (b b) c)))))" 

Above, a is the initial continuation, b is the argument x, and c is the 
continuation for the function. 

3 Encoding iteration in F ra 

In the previous section, we implemented iter as a recursive func- 
tion and used a recursive type, Rec, to define Exp. To prevent case 
analysis, we hid this definition of Rec behind a module boundary. 
However, this module abstraction and is not the only way to prevent 
case analysis. Furthermore, term and type recursion is not neces- 



sary to implement this datatype. We may define iter and Rec in 
the fragment of Haskell that corresponds to F m [10] so that iteration 
is the only elimination form for Rec. This implementation appears 
in Figure 4. 

The encoding is similar to the encoding of covariant datatypes in 
the polymorphic A.-calculus [3] (or to the encoding of Church nu- 
merals). We encode an expression of type Exp a as its elimination 
form. For example, something of type Exp a should take an elimi- 
nation function of type (ExpF a -> a) and return an a. To imple- 
ment cata we apply the expression to the elimination function. 

To create an expression, roll must encode this elimination. There- 
fore, roll returns a function that applies its argument f (the elimi- 
nation function) to the result of iterating over x. Again, to use xmap 
we need a right inverse for cata f . The term place in Figure 4 
is an expression that when analyzed returns its argument. We can 
show that place is a right inverse by expanding the above defini- 
tions: 

cata f . place = (\x -> cata f (place x)) 
= (\x -> (place x) f) 
= (\x -> ((\y -> x) f)) 
= (\x -> x) 



3.1 Reasoning about iteration 

There are powerful tools for reasoning about programs written in 
the polymorphic A.-calculus. For example, we know that all pro- 
grams that are written in F m will terminate. Therefore, we can ar- 
gue that the examples of the previous section are total on all in- 
puts that may be expressed in the polymorphic X-calculus, such as 
app (lam (\x -> app x x))(lam (\x -> app x x)). Un- 
fortunately, we cannot argue that these examples are total for ar- 
bitrary Haskell terms. For example, calling any of these routines on 
(lam (let fx = fxinf)) will certainly diverge. Further- 
more, even if the arguments to iteration are written in F^, if the op- 
eration itself uses type or term recursion, then it could still diverge. 
For example, using the recursive datatype Value from Section 2, 
we can implement the untyped ^.-calculus evaluator with iterO. 

Parametricity is another way to reason about programs written in 
F ro . As awkward as they may be, one of the advantages to pro- 
gramming with catamorphisms instead of general recursion is that 
we may reason about our programs using algebraic laws that follow 
from parametricity. While the following laws only hold for F m , we 
may be able to prove some form of them for Haskell using tech- 
niques developed by Johann [12]. 

Using parametricity, we can derive a. free theorem [28] about ex- 
pressions of type (forall a. (b a -> a) -> a). If x has this 
type, then 

f . f> = id and f . g = h . fst (xmap |b I (f ,f ' ) ) => 
f (x g) = x h 

The equivalence in this theorem is equivalence in some parametric 
model of Foo, such as the term model with (3r| -equivalence. Using 
the free theorem, we can prove a number of properties about itera- 
tion. First, we can show that iterating roll is an identity function, 
that iterO roll = id. Using this result we can show the unique- 
ness property for iter, which describes when a function is equal 
to an application of iter. It resembles an "induction principle" for 
iterO. 



f . f> = id and f . roll = h . fst (xmaplbl (f ,f ')) 
<=> f = iterO h 

The <= direction follows directly from the implementation of 
iterO and roll. The => direction follows from the free theorem. 

Finally, the fusion law can be used to combine the composition of 
a function f and an iteration into one iteration. This law follows 
directly from the free theorem. 



f = id 
iterO g 



and f . g = h 
= iterO h 



fst (xmaplbl (f ,f ')) => 



However, there is an important property about this encoding of the 
A,-calculus that we have not proven. Adequacy states that if a F m 
term is of type for all a. Exp a and is in canonical form, then 
it should be the encoding of the canonical form of some X-calculus 
expression. In other words, there is no extra "junk" in the type 
forall a. Exp a, such as badcase. As a first step towards prov- 
ing this result, we next show how this F m library can encode a lan- 
guage with iteration over HOAS that itself adequately embeds the 
A,-calculus. 

4 Enforcing parametricity with modal types 

In the next section, we formally describe the connection between 
the interface we have provided for iteration over higher-order ab- 
stract syntax and the modal calculus of Schiirmann, Despeyroux 
and Pfenning (SDP) [24]. We do so by using this library to give a 
sound and complete embedding of the SDP calculus into F ra . First, 
we provide a brief overview of the static and dynamic semantics of 
this calculus. The syntax of the SDP calculus is shown in Figure 5. 

The SDP calculus enforces the parametricity of function spaces 
with modal types. Modal necessity in logic is used to indicate those 
propositions that are true in all worlds. Consequently, these propo- 
sitions can make use of only those assumptions that are also true 
in all worlds. In Pfenning and Davies' [20] interpretation of modal 
necessity, necessarily true propositions correspond to those formu- 
lae that can be shown to be valid. Validity is defined as derivable 
with respect to only assumptions that themselves are valid assump- 
tions. As such, the typing judgments have two environments (also 
called contexts), one for valid assumptions, £2, and one for "local" 
assumptions, T. The terms corresponding to the introduction and 
elimination forms for modal necessity are box and let box. We 
give them the following typing rules: 

£2;0hM:A 



£2;YhboxM : DA 



£2;ThMi : DA\ £2ttl{x : Ai};T hM 2 :A 2 
£2; Y h let box x : A\ =M\ inM 2 : A 2 

A boxed term, M, has type DA only if it has type A with respect 
to the valid assumptions in £2, and no assumptions in local environ- 
ment. The let box elimination construct allows for the introduction 
of valid assumptions into £2, binding the contents of the boxed term 
Mi in the body M 2 . This binding is allowed because the contents 
of boxed terms are well-typed themselves with only valid assump- 
tions. Another way to think about modal necessity is that terms 
with boxed type are "closed" and do not contain any free variables, 
except those that are bound to closed terms themselves. 

Operationally, boxed terms behave like suspensions, while let box 
substitutes the contents of a boxed term for the bound variable. Be- 
cause the operational semantics is defined simultaneously with con- 



(Pure Types) B 
{Types) A 
(Terms) M 



{Term Replacement) 0 

{Pure Environment) *P 

{ Valid Environment) £2 

{Local Environment) T 

{Signatures) £ 



b | 1 | Bi -> B 2 | Si x B 2 

B | Ai -^A 2 | A v xA 2 | DA 

x\c\{) | Xx:A.M\M 1 M 2 | 

boxM | let box x:A = M\ inM 2 | 

{M u M 2 )\MM\sadM\ 

iter[Ai,A 2 ][Oj M 

0\@\H{xi-*M}\ 0a{ci-^M} 

0\W{x:B} 

0 j £2«{x : A} 

0 | Yu{x:A} 

0 j Lttl {<::£->■&} 



Figure 5. Syntax of SDP calculus 



version to canonical forms, it is parameterized by the environment 
*P that describes the types of free local variables appearing in the 
expression. 

"PhMi^ boxM'; : DA\ ¥ h M 2 {M[ /x}^V: A 2 
¥ h let box x : Ai = M x inM 2 ^>V :A 2 

To enforce the separation between the iterative and parametric func- 
tion spaces, the SDP calculus defines those types, B, that do not 
contain a □ type to be "pure". Objects in the calculus with type OB, 
boxed pure types, can be examined intensionally using an iteration 
operator, while objects of arbitrary impure type, A, cannot. This 
forces functions of pure type, he: B\..M : B\ — > B 2 , to be paramet- 
ric. This is because the input, x, to such a function does not have 
a boxed pure type, and there is no way to convert it to one — x 
will not be free inside of a boxed expression in M. Consequently, 
the functions of pure type may only treat their inputs extensionally, 
making them parametric. 

The language is parameterized by a constant type b and a signature, 
Z, of data constructor constants, c, for that base type. Each of the 
constructors in this signature must be of type B — > b. Because B is 
a pure type, these constructors may only take parametric functions 
as arguments. 

For example, consider a signature describing the untyped X- 
calculus, £ = {app : b x b — > £>,lam : (b — > b) — > b}, where the 
constant type b corresponds to Exp. Using this signature, we can 
write a function to count the number of bound variables in an 
expression, as we did in Section 2. 9 



countvar = Xx : Ob. 
iterpft, int] [{app h 
lam h- 



> Xy : mt.Xz : int.y + z, 
A,/:int-Mnt./l}]* 



The term iter intensionally examines the structure of the argu- 
ment x and replaces each occurrence of app and lam with 
Xy : \nt.Xz : int.y + z and Xf : int — ► int./l respectively. 

The typing rule for iter is the following: 

£2;TI-M:ne £2;YI-0:A<£) 
£2; Y h iter [OB, A] [&] M : A(B) 

The argument to iteration, M, must have a pure closed type to be 
analyzable. Analysis proceeds via walking over M and using the 



9 For simplicity, our formal presentation of SDP (in Figure 5) 
does not include integers. However, it is straightforward to extend 
this calculus to additional base types. 



replacement 0, a finite map from constants to terms, to substitute 
for the constants in the term M. The type A is the type that will 
replace the base type b in the result of iteration. The notation A(B) 
substitutes A for the constant b in the pure type B. Each term in 
the range of the replacements must also agree with replacing b with 
A. We verify this fact with the judgment £2; Y h © : A{Z), which 
requires that if 0(c) = M c and Z(c) = B c , then M c must have type 
A(B C ). 

Operationally, iteration in the SDP calculus works in the following 
fashion. 

fhM^ boxM' : DB 
0 h M' ft V' : B 
<PI- {A,V,@}(V')^V :A{B) 

¥ h iter [DS, A] [&]M^V :A(B) 

First, the argument to iteration M is evaluated, *P h M boxM' : 
□S, producing a boxed object M 1 . M' is then evaluated to r|-long 
canonical form via 0 h M' ft V' : 6. Next we perform elimination 
of that canonical form, {A, l P,0)(V / '), walking over V' and using 0 
to replace the occurrences of constants. Finally, we evaluate that 
result, V\- (A,¥,@){V')^>V :A(B). 

In order to simplify the presentation of the encoding, we have made 
a few changes to the SDP calculus. First, while the language pre- 
sented in this paper has only one pure base type b, the SDP calculus 
allows the signature Z to contain arbitrarily many base types. How- 
ever, the extension of the encoding to several base types is straight- 
forward. Also, in order to make the constants of the pure language 
more closely resemble datatype constructors, we have forced them 
all to be of the form B — > b instead of any arbitrary pure type B. To 
facilitate this restriction, we add unit and pairing to the pure frag- 
ment of the calculus so that constructors may take any number of 
arguments. 

5 Encoding SDP in F ro 

The terms that we defined in Section 3, roll and iter, correspond 
very closely to the constructors and iteration primitive of the SDP 
calculus. In this section, we strengthen this observation by showing 
how to encode all programs written in the SDP calculus into Fm 
using a variation of these terms. 

There are two key ideas behind our encoding: 

• We use type abstraction to ensure that the encoding of boxed 
objects obeys the closure property of the source language, and 
prevents variables from the local environment from appearing 
inside these terms. To do so, we parameterize our encoding by 
a type that represents the current world and maintain the in- 
variant that all variables in the local environment mention the 
current world in their types. Because a term enclosed within 
a box must be well-typed in any world, when we encode a 
boxed term we use a fresh type variable to create an arbitrary 
world. We then encode the enclosed term with that new world 
and wrap the result with a type abstraction. As a consequence, 
the encoding of a data-structure within a box cannot contain 
free local variables because their types would mention that 
fresh type variable outside of the scope of the type abstrac- 
tion. 

• We encode constants in the source language as their elimina- 
tion form with roll. Furthermore, we restrict the result of 
elimination to be of the type that is the world in which the 
term was encoded. However, the encoding of boxed expres- 



sions quantifies over that world, allowing the resulting com- 
putations to be of arbitrary type. 

The encoding of the SDP calculus can be broken into four primary 
pieces: the encodings for signatures, types, terms, and replace- 
ments. To simplify our presentation, we extend the target language 
with unit, void, products, and variants. The syntax of these terms 
appears in Figure 6. This extension does not weaken our results as 
there are well known encodings of these types into F^. In the re- 
mainder of this section, we present the details of the encoding and 
describe the most interesting cases. The full specification of this 
encoding appears in Appendix B. 

Signatures. The encoding of signatures in the SDP calculus, no- 
tated x(£), corresponds to generating the type constructor whose 
fixed point defines the recursive datatype. (For example, ExpF in 
Section 2.) The argument of the encoding, a specified world x, cor- 
responds to the argument of the type constructor. 

For this encoding, we assume the aid of an injective function L that 
maps data constructors in the source language to distinct labels in 
the target language. We also need an operation called parameteri- 
zation, notated x(B) and defined in Appendix B.l. This operation 
parameterizes pure types in the source calculus with respect to a 
given world in the target language, and produces a type in the tar- 
get language. Essentially, x(B) "substitutes" the type x for the base 
type, b, in B. 

We encode a signature as a variant. Each field corresponds to a 
constant c,- in the signature, with a label according to L, and a type 
that is the result of parameterizing the argument type of c,- with the 
provided type. 

Vc,edom(Z) L( Ci )=Bi^b 
x(T)±(L{c,):x(B x ),...,L{c n ):x{B n )) 

We often use parameterization and the signature translation to build 
type constructors in the target language, so we define the following 
two abbreviations: 

B* = Xa : *.a{B) Z* = A.cc : *.cc{Z) 

Types. As with the encoding of signatures, the encoding of types 
is parameterized by the worlds in which they occur. We write the 
judgment for encoding a type A in the source calculus in world x 
as A h A [> x x'. The environment A tracks type variables allocated 
during the translation and allows us to chose variables that are not 
in scope. The two interesting cases for encoding types from the 
source calculus are those for the base type and for boxed types. The 
case for b corresponds to Rec ExpF a from Section 3. Therefore, 
we define the abbreviation Rec Z* a = (Z*a — > a) — > a, intuitively 
a fixed point of Z*, to the same idea of encoding a datatype as its 
elimination form. 



AhfeOtRec Z* X 

The rule for boxed types uses type abstraction to ensure the result 
is parametric with respect to its world. Naively, we might expect 
to use a fresh type variable as the new world and then encode the 
contents of the boxed type with that type variable. This encoding 
ensures that the type is parametric with respect to its world and then 
quantifies over the result. 

a^A Aula : *} \-A> a t' 

— — — - w ; WRONG! 

Ah DAi> T Va:*.x' 



(Kinds) k ::= * | K t — > k 2 

(Types) x ::= 1 | 0 | a | Ti — ► T2 | Va:K.x 1 Xi x x 2 \ {h '■ Xi, . . . ,l n : x„) | ha : k.t | a | X1X2 

(Terms) e ::= x \ () \ Xx : X.e \ e\e2 \ Aa.K.e \ e[x] \ {e\,e2} | fste | snde | inj/eofx | 

caseeofinj^ x\ inei . . . inj; x„ ine„ 
(Type Variable Environment) A ::= 0 | Atbl {a : k} 
(Term Environment) T ::= 0 | TW {x : x} 

Figure 6. Syntax of F a with unit, void, products, and variants 



However, with this encoding we violate the invariant that the types 
of all free local variables mention the current world, because the 
encoding does not involve x. Instead, we use the fresh type vari- 
able to create a new world from the current world and consider a 
as a "world transformer". During the translation, a term will be en- 
coded with a stack of world transformers, somewhat akin to stack 
of environments in the implicit formulation of modal types [7]. 



a^A Au{a : * — > *} h At> aT t' 
Ah DAo-tVa:*^ *.x' 

The naive translation of the unit type also forgets the current world. 
For this reason, we add a non-standard unit to V w that is parameter- 
ized by the current world. In other words, the unit type 1 is of kind 
*— >* and the unit term {) has type Va:*. 1(a). Our type translation 
instantiates this type with the current world. 



Ah 1> X 1[t] 

The remaining types in the SDP language are encoded recursively 
in a straightforward manner. The complete rules can be found in 
Appendix B.3. 

Terms and replacements. We encode the source term, M, with 
the judgment A; E h M \> % e. In addition to the current world, x, 
and the set of allocated type variables, A, the encoding of terms 
is also parameterized by a set of term variables, E. This set of 
variables allows the encoding to distinguish between variables that 
were bound with X and those bound with let box. We will elaborate 
on why this set is necessary shortly. 

Our encoding of boxed terms follows immediately from the encod- 
ing of boxed types. Here we encode the argument term with respect 
to a fresh world transformer applied to the present world and then 
wrap the result with a type abstraction. 

a^A AU{a : *— > *};E h Mt> ax e 
A;E h boxMOx Aa:* — > *.e 

We encode let box by converting it to an abstraction and application 
in the target language. However, one might note the discrepancy 
between the type of the variable we bind in the abstraction and the 
type we might naively expect. 

Ah QAj t> x X] 
A; Eh Mi O x ei A;EU {x} h M2 >x ^2 

A;E h let boxx : A] =M\ inM2 > T (he : X\.e2)e\ 

The type of x is A\ and so one might assume that the type of x in 
the target should be the encoding of A 1 in the world x. However, 
let box allows us to bind variables that are accessible in any world 
and using A\ encoded against x would allow the result to be used 



cata : Va:*.(£*oc^ a) — » (Rec Z* a) — > a 
cata = Aa:*..\f : (L*a^ a).Xy : (Rec Z* a).yf 

place : Va : *.a — > Rec Z* a 

place = Aa:*.Aj: : a.Xf : (Z*a — > a).x 

xmap{|x|} : Voc:*.Vf5:*.(a^ p x (3 — > a) —> 
(xa — > xp x xp — > xa) 

openiter{|x|} : Va:*.(£*a — > a) — > x(Rec L* a) -> xa 
openiter{|x|} = Aa:*.Xf : S*a — ► a. 

fst(xmap{|x|}[Rec Z* a][a]{cata[a]/,place[a])) 

iter{| x|} : Vy: *.Va : *. (£* a a) 

(V(3:*^*.x(Rec£* ($y)) xa 
iter{|x|} = Ay:*.Aa:*.X/ : Z*a^ a. 

h : (V(3 : * -> *.x(Rec Z* (Py))).openiter{|x|}[a]/(x[a]) 

roll : Va:*.£*(Rec Z* a) -> Rec Z* a 
roll= Aa:*.Xx:Z*(Rec Z* a). 
A/:£*a-> a./(openiter{|Z* |} [a] / x) 

Figure 7. Library routines 



only in the present world. Because the encoding of M\ will evalu- 
ate to a type abstraction, a term parametric in its world, we do not 
immediately unpack it by instantiating it with the current world. 
Instead we pass it as x and then, when x appears we instantiate it 
with the current world. Consequently, we use E to keep track of 
variables bound by let box. When encoding variables, we check 
whether x occurs in E and perform instantiations as necessary. 

xeZ 

A;Ehxt> x x A;Ehi> t i[Xa:*.x] 

If the variable is in E, then it is applied to a world transformer that 
ignores its argument, and returns the present world. This essentially 
replaces the bottom of the world transformer stack captured by the 
type abstraction substituted for x with the world x. Doing so ensures 
that if we substitute the encoding of a boxed term into the encoding 
of another boxed term, the type correctness of the embedding is 
maintained by correctly propagating the enclosing world. 

Figure 7 shows the types and definitions of the library routines used 
by the encoding. The only difference between it and Figure 4 is 
that iter abstracts the current world and requires that its argument 
be valid in any transformation of the current world. Again, we 
make use of the polytypic function xmap to lift cata to arbitrary 
type constructors . Because xmap is defined by the structure of 
a type constructor x, we cannot directly define it as a term in F^. 
Instead, we will think of xmap{|x|} as macro that expands to the 



mapping function for the type constructor x. (We use the notation 
{]•[} to distinguish between polytypic instantiation and parametric 
type instantiation.) This expansion is done according to the defini- 
tion in Appendix A. We do not cover the implementation here, see 
Hinze [11] for details. 

Encoding constants in the source calculus makes straightforward 
use of the library routine roll. We simply translate the constant into 
an abstraction that accepts a term that is the encoding of the argu- 
ment of the constant, and then uses roll to transform the injection 
into the encoding of the base type, Rec S* x. 

Z(c)=B->b AhBOtXB 
A;Shct,k: x^rolIptKinj^x of Z* (Rec Z* x)) 

The encoding of iteration is similarly straightforward. We instanti- 
ate our polytypic function iter with a type constructor created from 
parameterizing B, and then apply it to the current world and the en- 
codings of the intended result type A, the replacement term 0 and 
argument term M. 

A\-A> x x A A;E h &>l A e% A;EhM> x e M 
A; E h iter [DS, A] [0] Mt> x iter{]B* |} [x] [x A ] e @ e M 

The encoding of replacements 0 is uncomplicated and analogous 
to the encoding of signatures. We construct an abstraction that con- 
sumes an instance of an encoded signature, dispatching the variant 
using a case expression. In each branch, the encoding of the corre- 
sponding replacement is applied to the argument of the injection. 

Vcj € dom(0) A; E h ®(Q) > x e t 
A;E h & >l A Ax : Z*x j 4.casexofinj x( - ei - 1 y\ in(eiyi) 

' m iL(c n )yn«i{e n y n ) 

The encodings for the other terms in the source language are 
straightforward and appear in Appendix B.4. Now that we have 
defined all of our encoding for any closed term M in the SDP cal- 
culus, we put everything together to construct a term e in our target 
calculus using the initial judgment 0; 0 h M >q e. We use the void 
type as the initial world to enforce the parametricity of unboxed 
constants. 

5.1 Properties of the encoding 

We have proven a number of desirable properties concerning this 
encoding. However, before we can state these properties, we must 
first define the relationship between the environments in the source 
and target calculi. These relations hold when all types from the 
local environment are encoded with the current world, and all types 
from the valid environment are first boxed then encoded with any 
world. 

Definition 5.1 (Encoding typing environments). We 
write A h T t> x Ty and A h £1 1> r 2 to mean that 

Vx : A <E Y,x : X A € T\ when A h A [> t X A 
Vx : A € £l,x : X A <E r 2 when there exists A h x' such that 
Ah DAr> x rt A 

The relation for valid environments above is not parameterized by 
the current world. A single valid environment may be encoded as 
many different target environments, depending on what worlds are 
chosen for each type in the environment. However, in some sense 
the encodings are equivalent. If the translation of M type checks 



with one encoding of £1, it will type check with any other encoding 
offl 

The encoding is type preserving. If we encode a well-typed term 
M, the resulting term will be well-typed under the appropriately 
translated environment. Furthermore, the converse is also true. If 
the encoding of a term M is well-typed in the target language, then 
M must have been well-typed in the source. This means that the 
target language preserves the abstractions of the source language. 

Theorem 5.2 (Static correctness). Assume A I- x and 
AhYOtT! andA\-£lt>r 2 . 

1. //A;dom(f2) h M> x e then 

H;T h M : A and Ah A> x z A <^> A;Ti «r 2 h e : x A 

2. //A;dom(ii)h0t>^e e *e« 

n;Th0:A(£) and Ah Al> t x A <s> A;Ti «r 2 h e e : x A (L) -> x A 

PROOF. By mutual induction over the translation 
of terms (A;dom(fl) h M I> t e) and of replacements 
(A;dom(fl)h01>^ee)- □ 

Furthermore, source evaluation and canonicalization is the same as 
(3r| -equivalence in the target calculus. 

Theorem 5.3 (Dynamic correctness). // 0\ v ¥\-M:A 
and 0;>PI-M> t c and 0 h V t> x e' and 0hAl> t X A and 
0;Eh 0; > Pi> T r then 

1. I'hM^ViA <(=> 0;rhe= |3tl e':x A . 

2. I'hMUViA o 0;rhe= |3tl e':x A . 

PROOF. The forward direction follows by simultaneous induction 
on the evaluation of M Q¥ h M <— > V : A) and the conversion of M 
to canonical form fPhMfy: A). The reverse direction follows 
from the forward direction and from the fact that evaluation in the 
SDP calculus is deterministic and total. □ 

6 Future work 

Although we have shown a very close connection between SDP 
and its encoding in F a , we have not shown that this encoding is 
adequate. We would like to show that if x is the image of an SDP 
type, then all terms of type x are equivalent to the encoding of some 
SDP term. In other words, there is no extra "junk" of type x. Show- 
ing this result would also show that encoding the X-calculus with 
app and lam is adequate, because the SDP calculus can already 
adequately encode the X-calculus. 

Alternatively, we could try to show adequacy with respect to the X- 
calculus directly using a different method. It may also be possible to 
do so for the simpler encoding of modal types, informally presented 
in the first part of the paper, that uses first-order quantification and 
discards the current world. Whereas this simpler encoding allows 
the translation of some terms that are rejected by the SDP calculus 
to type check (for example, Ax : Ob. box x), it may still be adequate 
for encoding the untyped A-calculus. 

One important extension of this work is the case operator. Because 
there are limitations to what may be defined with iter, the SDP 
calculus also includes a construct for case analysis of closed terms. 



However, we have not yet found an obvious correspondence for 
case in our encoding. 

Another further area of investigation is into the dual operation to 
iter, the anamorphism over datatypes with embedded functions. 
An implementation of this operation, called coiter, is below. The 
coiter term is an anamorphism — it generates a recursive data 
structure from an initial seed. 

data Dia f a = In (f (Dia fa), a) 

coroll : : Dia f a -> f (Dia f a) 
coroll (In x) = fst x 
coplace : : Dia f a -> a 
coplace (In x) = snd x 

coiterO : : (a -> f a) -> a -> (exists a. Dia f a) 
coiterO g b = 

In (snd (xmap (coplace, coiterO g) (g b) ) , b) 

Instead of embedding the recursive type in a sum, we embed it in 
a product. The two selectors from this product have the dual types 
to roll and place. In the definition of coiterO we use coplace 
as the inverse where we would have used cata in the definition of 
ana. A term of type (exists a. Dia b a) corresponds to the 
possibility type (o b) in a modal calculus. However, while a general 
anamorphism is an inverse of a catamorphism, coiter is not an 
inverse to iter. In fact, iter cannot consume what coiter pro- 
duces, giving doubts to its practical use. (On the other hand, ana 
itself has seen little practical use for datatypes with embedded func- 
tions.) From a logical point of view, this restriction makes sense. 
Combining anamorphisms and catamorphisms (even for datatypes 
without embedded functions) leads to general recursion. 

7 Related work 

The technique we present, using polymorphism to enforce para- 
metricity, has appeared under various guises in the literature. For 
example, Shao et al. [27] use this technique (one level up) to imple- 
ment type-level intensional analysis of recursive types. They use 
higher-order abstract syntax to the represent recursive types and re- 
mark that the kind of this type constructor requires a parametric 
function as its argument. However, they do not make a connec- 
tion with modal type systems, nor do they extend their type-level 
iteration operator to higher kinds. Xi et al. [31] remark on the cor- 
respondence between HOAS terms with the place operator (which 
they call HOASvar) and closed terms of Mini-ML^? but do not in- 
vestigate the relationship or any form of iteration. 

While higher-order abstract syntax has an attractive simplicity, the 
difficulties programming and reasoning about structures encoded 
with this technique have motivated research into language exten- 
sions for working with higher-order abstract syntax or alternative 
approaches altogether. Dale Miller developed a small language 
called ML^ [17] that introduces a type constructor for terms formed 
by abstracting out a parameter. These types can be thought of as 
function types that can be intensionally analyzed through pattern 
matching. Pitts and Gabbay built on the theory of FM-sets to de- 
sign a language called FreshML [23] that allows for the manipu- 
lation and abstraction of fresh "names". Nanevski [18] combines 
fresh names with modal necessity to allow for the construction of 
more efficient residual terms, while still retaining the ability to eval- 
uate them at runtime. The Delphin Project [25] by Schiirmann et al. 
develops a functional language for manipulating datatypes that are 
terms in the LF logical framework. Because higher-order abstract 



syntax is the primary representation technique in LF, Delphin pro- 
vides operations for matching over higher-order LF terms in regular 
worlds. The SDP calculus uses modal necessity to restrict match- 
ing to closed worlds, so regular worlds provide additional flexi- 
bility without the difficulties of matching in an open world. The 
Hybrid [2] logical framework provides induction over higher-order 
abstract syntax by evaluation to de Bruijn terms, which provide 
straightforward induction. 

There is a long history of encoding modality in logic, but only re- 
cently has the encoding of modal type systems been explored. Acar 
et al. [1] use modal types in a functional language that provides con- 
trol over the use of memoization, and implement it as a library in 
SML. Because SML does not have modal types or first-class poly- 
morphism, they use run-time checks to enforce the correct use of 
modality. Davies and Pfenning [7] presented, in passing, a simple 
encoding of the modal X-calculus into the simply-typed A.-calculus 
that preserves only the dynamic semantics. Washburn expanded 
upon this encoding, showing that it bisimulates the source calcu- 
lus [29]. 

8 Conclusion 

While other approaches to defining an induction operator over 
higher-order abstract syntax require type system extensions to en- 
sure the parametricity of embedded function spaces, the approach 
that we present in this paper requires only type polymorphism. Be- 
cause of this encoding, we are able to implement iteration operators 
for datatypes with embedded parametric functions directly in the 
Haskell language. 

However, despite its simplicity, our approach is equivalent to pre- 
vious work on induction operators for HOAS. We demonstrate this 
generality by showing how the modal calculus of Schiiermann, De- 
speyroux and Pfenning may be embedded into F^ using this tech- 
nique. In fact, the analogy of representing boxed terms with poly- 
morphic terms makes semantic sense: a proposition with a boxed 
type is valid in all worlds and polymorphism makes that quantifica- 
tion explicit. 

Acknowledgements 

We thank Margaret DeLap, Eijiro Sumi, Stephen Tse, Stephan 
Zdancewic and the anonymous ICFP reviewers for providing us 
with feedback concerning this paper. 

9 References 

[1] U. Acar, G. Blelloch, and R. Harper. Selective memoiza- 
tion. In Thirtieth A CMS1GPLAN- SIGA CT Symposium on 
Principles of Programming Languages, New Orleans, LA, 
Jan. 2002. 

[2] S. Ambler, R. L. Crole, and A. Momigliano. Combining 
higer order abstract syntax with tactical theorem proving and 
(co)induction. In Theorem Proving in Higher Order Logics, 
15th International Conference, TPHOLs 2002, Hampton, VA, 
USA, August 20-23, 2002, Proceedings, volume 2410 of Lec- 
ture Notes in Computer Science. Springer, 2002. 

[3] C. Bohm and A. Berarducci. Automatic synthesis of typed 
A- programs on term algebras. Theoretical Computer Science, 
39:135-154, 1985. 



[4] A. Church. A formulation of the simple theory of types. Jour- 
nal of Symbolic Logic, 5:56-68, 1940. 

[5] D. Clarke, R. Hinze, J. Jeuring, A. Loh, and J. de Wit. The 
Generic Haskell user's guide. Technical Report UU-CS-2001- 
26, Utrecht University, 2001. 

[6] O. Danvy and A. Filinski. Representing control: a study of the 
CPS transformation. Mathematical Structures in Computer 
Science, 2(4):361-391, Dec. 1992. 

[7] R. Davies and F. Pfenning. A modal analysis of staged com- 
putation. Journal of the ACM, 48(3):555-604, May 2001. 

[8] J. Despeyroux and P. Leleu. Recursion over objects of func- 
tional type. Mathematical Structures in Computer Science, 
11:555-572,2001. 

[9] L. Fegaras and T. Sheard. Revisiting catamorphisms over 
datatypes with embedded functions (or, programs from outer 
space). In Twenty-Third ACMSIGPLAN-SIGACT Symposium 
on Principles of Programming Languages, pages 284—294, 
St. Petersburg Beach, FL,USA, 1996. 

[10] J.-Y. Girard. Une extension de 1' interpretation de Godel a 
l'analyse, et son application a l'elimination de coupures dans 
l'analyse et la theorie des types. In J. E. Fenstad, editor, Pro- 
ceedings of the Second Scandinavian Logic Symposium, pages 
63-92. North-Holland Publishing Co., 1971. 

[11] R. Hinze. Polytypic values possess polykinded types. Science 
of Computer Programming, 43(2-3): 129-159, 2002. MPC 
Special Issue. 

[12] P. Johann. A generalization of short-cut fution and its cor- 
rectness proof. Higher-Order and Symbolic Computation, 
15:273-300, 2002. 

[13] M. P. Jones. A system of constructor classes: overloading and 
implicit higher-order polymorphism. Journal of Functional 
Programming, 5(1), Jan. 1995. 

[14] M. P. Jones. Type classes with functional dependencies. In 
Proceedings of the 9th European Symposium on Program- 
ming, ESOP 2000, Berlin, Germany, number 1782 in LNCS. 
Springer- Verlag, 2000. 

[15] E. Meijer, M. M. Fokkinga, and R. Paterson. Functional pro- 
gramming with bananas, lenses, envelopes and barbed wire. 
In FPCA91: Conference on Functional Programming Lan- 
guages and Computer Architecture, pages 124-144, 1991. 

[16] E. Meijer and G. Hutton. Bananas in space: Extending fold 
and unfold to exponential types. In FPCA95: Conference on 
Functional Programming Languages and Computer Architec- 
ture, pages 324-333, La Jolla, CA, June 1995. 

[17] D. Miller. An extension to ML to handle bound variables 
in data structures: Preliminary report. In Proceedings of the 
Logical Frameworks BRA Workshop, May 1990. 

[18] A. Nanevski. Meta-programming with names and neces- 
sity. In Proceedings of the seventh ACM SIGPLAN inter- 
national conference on Functional programming, pages 206- 
217. ACM Press, 2002. 

[19] S. Peyton Jones, editor. Haskell 98 Language and Libraries: 
The Revised Report. Cambridge University Press, 2003. 

[20] F. Pfenning and R. Davies. A judgmental reconstruction of 
modal logic. Mathematical Structures in Computer Science, 
ll(4):511-540, Aug. 2001. 

[21] F. Pfenning and C. Elliott. Higher-order abstract syntax. In 



1988 ACM SIGPLAN Conference on Programming Language 
Design and Implementation, pages 199-208, Atlanta, GA, 
USA, June 1988. 

[22] F. Pfenning and C. Schiirmann. System description: 
Twelf — a meta-logical framework for deductive systems. In 
H. Ganzinger, editor, Proceedings of the 16th International 
Conference on Automated Deduction (CADE-16), pages 202- 
206, Trento, Italy, July 1999. 

[23] A. M. Pitts and M. Gabbay. A metalanguage for program- 
ming with bound names modulo renaming. In Mathematics 
of Program Construction, pages 230-255, 2000. 

[24] C. Schiirmann, J. Despeyroux, and F. Pfenning. Primitive re- 
cursion for higher-order abstract syntax. Theoretical Com- 
puter Science, 266(1-2): 1-58, Sept. 2001. 

[25] C. Schiirmann, R. Fontana, and Y. Liao. Delphin: Functional 
programming with deductive systems. Available at http : / / 
cs-www . cs . yale . edu/homes/ car sten/, 2002. 

[26] E. Sumii and N. Kobayashi. A hybrid approach to online and 
offline partial evaluation. Higher-Order and Symbolic Com- 
putation, 14(2/3): 101-142, 2001. 

[27] V. Trifonov, B. Saha, and Z. Shao. Fully reflexive intensional 
type analysis. In Fifth ACM SIGPLAN International Con- 
ference on Functional Programming, pages 82-93, Montreal, 
Sept. 2000. 

[28] P. Wadler. Theorems for free! In FPCA89: Conference on 
Functional Programming Languages and Computer Architec- 
ture, London, Sept. 1989. 

[29] G. Washburn. Modal typing for specifying run-time code 
generation. Available from http : / /www . cis . upenn . edu/ 
~geof f w/research/, 2001. 

[30] S. Weirich. Higher-order intensional type analysis in 
type-erasure semantics. Available from http://www.cis. 
upenn.edu/~sweirich/, 2003. 

[31] H. Xi, C. Chen, and G. Chen. Guarded recursive datatype con- 
structors. In Thirtieth ACMSIGPLAN-SIGACT Symposium on 
Principles of Programming Languages, pages 224-235, New 
Orleans, LA, USA, Jan. 2003. 

A Generic Haskell implementation of xmap 

type XMap { [*] } tl t2 = (tl -> t2, t2 -> tl) 
type XMap {[k -> 1]> tl t2 = forall ul u2 . 
XMap {[k]} ul u2 -> XMap { [1] }(tl ul) (t2 u2) 

xmap { I t : : k I } : : XMap { [k] } t t 
xmap -CI Unit 1} = (id, id) 

xmap -CI : + : 1} (xmapAl ,xmapA2) (xmapBl ,xmapB2) = 
(\x -> case x of 
(Inl a) -> Inl (xmapAl a) 
(Inr b) -> Inr (xmapBl b) , 
\x -> case x of 
(Inl a) -> Inl (xmapA2 a) 
(Inr b) -> Inr (xmapB2 b)) 
xmap -(I :*: 1} (xmapAl , xmap A2) (xmapBl ,xmapB2) = 
(\(a :*: b) -> (xmapAl a) :*: (xmapBl b) , 
\(a :*: b) -> (xmapA2 a) :*: (xmapB2 b)) 
xmap -(I (->) |} (xmapAl ,xmapA2) (xmapBl ,xmapB2) = 
(\f -> xmapBl . f . xmapA2, 
\f -> xmapB2 . f . xmapAl) 
xmap {I Int 1} = (id, id) 



xmap {| Bool 1} = (id, id) 
xmap {| 10 |} (xmapAl ,xmapA2) = 

(fmap xmapAl, fmap xmapA2) 
xmap {| [] |} (xmapAl ,xmapA2) = 

(map xmapAl, map xmapA2) 

B Full encoding of SDP 
B.l Parameterization 

T(gl> = Ti x{fi 2 )=X 2 

X{b) = % X(1>=1 S 2 ) = Xi T 2 

T(Bl) = Ti x{fi 2 ) = X 2 
x(Si x fl 2 ) = X] x x 2 

B.2 Signatures 

Vc; € dom(Z) £(c;) = B t ^b 
x(E)^(X(c 1 ):x(B 1 },...,X(c„):x(B„}) 

B.3 Types 

A I_ T a^A Au{a : *^ *} hAt> at t' 

Ah fct> t Rec Z* x Ah DAi> t Va:*^*.x' 

AhAi> x Ti AhA 2 > x X 2 
Ahl> T l(x) A h Ai A 2 >tXi — » X2 

AhAi> T Xi AhA2>xX2 
A h Ai X A2 t>iXl X T2 



B.4 Terms 

-*0S X £ 5 

A;Ehxi> x x A;S h xt> t x[Aa : *.x] 

OC^A AU {a : * — > *};E h Mt> m e 

A;S h boxMo-tAa:*^ *.e A;Eh ()>,{)['[] 

£(c)=B->fc Ahfio t x B 
A;E h ct> T Ax : Xfl.roll[x](inj x / c )Xof (Rec Z* x)(E}) 

A;EhM[> t e AhAi> x Xi 
A;S h Ax :A\Mt>i Ax : X\.e 

A;EhMiI> T ei A;EhM2>x«2 
A;E h M\Mi l>T,e\e2 

Ah DAi I> t Xi 
A;EhMiI> x ei A; E ttl {x} h M 2 >t e 2 

A; E h let box x:A\ = M\ inM2 l> T (Xx : Va.Xi .£2)^1 

A;ShM, t> T ei A;EhM 2 t> t e2 A;EhMt> T e 
A;E h (Mi,M 2 )> T <ei,C2) A;E h fstMo T fste 

A;E h Mt> x e 
A;E h sndM> t snde 

AhAl> x x A A; Eh ®X>\ A e® A;Z\- Mo x e M 
A; E h iter [QB,A] [0] M [> T iter{|S* |} [x] [x A ] e Q e M 

B.5 Replacements 

Vq £ dom(0) A; E h 0(c,-) > T e; 
A;E h Xx : E*XA.casexofinj X ( Cl )yi in(eiyi) 

in Ji:( e „)>'« in ( e »>'«) 



